Skip to content

Ft8 integration; round 2 - #17

Open
dlsolt wants to merge 9 commits into
KI3P:mainfrom
dlsolt:ft8-integration
Open

Ft8 integration; round 2#17
dlsolt wants to merge 9 commits into
KI3P:mainfrom
dlsolt:ft8-integration

Conversation

@dlsolt

@dlsolt dlsolt commented Feb 6, 2026

Copy link
Copy Markdown
Contributor

Added Oliver's suggestions to the code.

@KI3P

KI3P commented Feb 7, 2026

Copy link
Copy Markdown
Owner

I get the following error when I try to compile. Is there a missing file that defines a new data type?

Phoenix/code/src/PhoenixSketch/MainBoard_AudioIO.cpp:129:1: error: 'AudioOutputUSB' does not name a type; did you mean 'AudioOutputTDM'?
  129 | AudioOutputUSB usbOut;

@KI3P

KI3P commented Feb 7, 2026

Copy link
Copy Markdown
Owner

I get the following error when I try to compile. Is there a missing file that defines a new data type?

Phoenix/code/src/PhoenixSketch/MainBoard_AudioIO.cpp:129:1: error: 'AudioOutputUSB' does not name a type; did you mean 'AudioOutputTDM'?
  129 | AudioOutputUSB usbOut;

I just configured GitHub to attempt to compile a pull request before allowing it to merge. This will help test for cases like this for future PRs (don't think the rule will run against this PR which was submitted before the change)

dlsolt added 6 commits July 3, 2026 15:12
# Conflicts:
#	code/src/PhoenixSketch/Loop.cpp
#	code/src/PhoenixSketch/SDT.h
Upstream renamed BUFFER_SIZE to USB_BUFFER_SIZE in SDT.h to avoid a
namespace conflict with another library, and updated DSP.cpp's non-FT8
code accordingly. This left three references in the FT8 additions
(PlayUsbBufferPreVol's test tone generator and ReadMicrophoneBuffer's
FT8 sample path) still using the now-undefined BUFFER_SIZE macro.
Ft8UsbBridge_DrainToUSB() was the only project code calling a
core_mods-only function (usb_audio_push_block) -- confirmed by searching
src/ for it and the other three core_mods additions
(usb_audio_pop_receive_block, usb_audio_tx_has_room,
usb_audio_manual_transmit), none of which are otherwise referenced.

core_mods/usb_audio.h now defines T41_CORE_HAS_USB_AUDIO_PUSH_BLOCK next to
the push_block declaration, so project code can detect at compile time
whether the patched core is installed. Anyone re-copying this header into
a Teensyduino install must bring this #define along -- applied here to
both the repo copy and the installed copy at
AppData/Local/Arduino15/packages/teensy/hardware/avr/1.62.0/cores/teensy4/.

When the sentinel is absent, Ft8UsbBridge_DrainToUSB() drops the buffered
RX samples instead of calling the missing function, with a #warning at the
top of the file explaining why. FT8 TX (PC -> radio) is unaffected since it
never depended on the core patch.

compile.yml gains a second, independent job (compile-usb-audio) that
builds with usb=serialmidiaudio against CI's stock-installed core, so the
FT8 code path actually gets compiled and the new gate gets exercised
instead of silently skipping (the existing usb=serial2 job never defines
USB_AUDIO/USB_MIDI_AUDIO_SERIAL, so it excludes this code entirely and
proves nothing about it).
… just T41_USB_AUDIO

usb_audio.h wraps AudioInputUSB/AudioOutputUSB themselves in
#ifdef AUDIO_INTERFACE, which boards.txt only defines for USB Type =
Audio / Serial+MIDI+Audio. T41_USB_AUDIO (Config.h) is independent of that
board menu selection, so a usb=serial2 build previously still tried to
declare AudioInputUSB g_usbIn -- compile failure ("does not name a type"),
plus several call sites (Ft8UsbBridge_SetTxActive at
MainBoard_AudioIO.cpp:379/402, Ft8UsbBridge_Init at
MainBoard_AudioIO.cpp:570/Globals.cpp:518, Ft8UsbBridge_DrainToUSB at
MainBoard_AudioIO.cpp:575) called into functions that wouldn't even be
defined in that configuration -- link failures waiting to happen.

Restructured Ft8UsbBridge.cpp: the RX FIFO plumbing, Ft8UsbBridge_PutRxSamples,
Ft8UsbBridge_DrainToUSB (its only interface-dependent line already gated by
T41_CORE_HAS_USB_AUDIO_PUSH_BLOCK), and Ft8UsbBridge_SetTxActive never
touched AudioInputUSB/AudioOutputUSB in the first place, so they're now
defined unconditionally -- fixing every mismatched caller above without
touching the callers themselves. Only Ft8UsbBridge_Init/Ft8UsbBridge_GetSamples
and the AudioInputUSB/AudioRecordQueue/AudioConnection objects they depend on
stay behind the strict #if defined(T41_USB_AUDIO) && (defined(USB_AUDIO) ||
defined(USB_MIDI_AUDIO_SERIAL)) guard, with safe stubs (silence/no-op) in
the #else so callers don't need to know which USB Type is selected.

Audited every reference to AudioOutputUSB, AudioInputUSB, usb_audio_, and
Ft8UsbBridge_* under src/: CAT.cpp/Loop.cpp/MainBoard_DisplayHome.cpp only
call the always-defined GetFt8Mode()/SetFt8Mode(), and MainBoard_AudioIO.cpp's
Q_usbOut_L/R/usbRxGainL/R (AudioPlayQueue/AudioAmplifier) don't require
AUDIO_INTERFACE at all -- none of those needed changes.
@dlsolt

dlsolt commented Jul 4, 2026

Copy link
Copy Markdown
Contributor Author

All checks now green. Since your comment: the compile error was FT8 code gated only on T41_USB_AUDIO (Config.h) without also checking the board's USB Type provides the audio interface — fixed so all configurations build: USB Serial (FT8 compiled out), Serial+MIDI+Audio on stock core (RX-to-PC path stubbed with a #warning — see core_mods/README for why the 2-file core patch is needed), Serial+MIDI+Audio with core_mods applied (full FT8, verified on air). Also added a second CI job compiling the USB-audio configuration — happy to drop it if you'd rather keep compile.yml minimal. Stock-core feasibility analysis is in docs/EXPERIMENT_LOG.md. Ready for review.

@tmr4

tmr4 commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Has a spectral analysis been done on the TX signal? Just listening to the signal or making successful contacts isn't sufficient. It doesn't make sense that a transfer from the PC at 48kHz to the T41 at 192kHz without modification will yield a pure FT8 transmission. The smoking gun is that modification is needed from the T41 to the PC.

@dlsolt

dlsolt commented Jul 7, 2026

Copy link
Copy Markdown
Contributor Author

I have not done a spectral analysis. i'll look into that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants